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Executive  Summary 


Building  on  relevant  best  practices  extracted  from  the  Capability  Maturity  Model®  Integra¬ 
tion  (CMMI®)  framework,  this  report  defines  effective  and  efficient  practices  for  acquisition 
projects.  These  best  practices  focus  on  the  activities  performed  by  acquisition  professionals  in 
the  acquisition  program  office.  They  also  address  internal  program  office  activities  that  sup¬ 
port  the  monitoring  and  control  of  development  contractors  and  suppliers.  They  provide  a 
foundation  for  acquisition  process  discipline  and  rigor  that  enables  product  and  service  de¬ 
velopment  to  be  repeatedly  executed  with  high  levels  of  ultimate  acquisition  success. 

This  report  documents  acquisition  practices  that  should  be  performed  by  government  acquisi¬ 
tion  projects  acquiring  systems  or  services.  These  practices,  however,  can  also  be  used  by 
non-government  organizations  to  improve  their  acquisition  practices.  This  report  does  not 
contain  prescribed  implementation  approaches  for  achieving  acquisition  best  practices.  In¬ 
stead,  the  proven  content  of  the  CMMI  framework  is  used  as  a  base,  and  amplifications  that 
are  specific  to  the  acquisition  process  have  been  added. 

The  information  in  this  report  can  also  be  used  by  acquisition  organizations  that  manage  sev¬ 
eral  related  acquisition  projects  (e.g.,  product  centers,  acquisition  commands.  Program  Ex¬ 
ecutive  Officers,  Service/Component  acquisition  executives)  to  establish  an  acquisition  proc¬ 
ess  improvement  program,  ensuring  the  success  of  projects  in  their  purview. 


®  Capability  Maturity  Model  and  CMMI  are  registered  in  the  U.S.  Patent  and  Trademark  Office  by 
Carnegie  Mellon  University. 
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1  Introduction 


The  CMMl  Acquisition  Module  (CMMI-AM)  is  a  stand-alone  guide  that  describes  best  prac¬ 
tices  for  use  in  the  acquisition  of  products.  It  focuses  primarily  on  effective  acquisition  activi¬ 
ties  and  practices  that  are  implemented  by  first-level  acquisition  projects,  such  as  those  con¬ 
ducted  by  a  System  Program  Office/Program  Manager.  The  information  contained  in  this 
report  can  also  be  used  by  organizations  that  manage  multiple  programs  (e.g.,  product  cen¬ 
ters,  acquisition  commands,  Program  Executive  Officers,  Service/Component  acquisition 
executives,  etc.)  to  implement  organizational  process  improvement  activities.  These  activities 
help  establish  the  environment  and  infrastructure  required  to  increase  project  success  of  the 
projects  within  their  portfolios  (see  the  section  “Improving  Acquisition  Practices”  in  the  Ap¬ 
pendix). 

1.1  Purpose  and  Goals 

Acquisition  activities  are  complex  because  acquisition  projects  are  directed  outwardly  toward 
acquiring  products,  systems,  services,  and  capabilities  from  developers  to  meet  a  set  of  opera¬ 
tional  expectations  and  inwardly  toward  ensuring  the  acquisition  process  itself  is  conducted 
with  rigor.  The  CMMI-AM  incorporates  this  duality  by  recognizing  that  some  of  these  ac¬ 
tivities  are  under  the  direct  control  of  the  acquisition  project,  while  others  are  directed  toward 
monitoring  or  facilitating  success  of  development  or  operational  partners. 

Lack  of  acquisition  guidance  is  a  major  concern  for  projects  involved  in  the  acquisition  and 
sustainment  of  systems,  including  software-intensive  systems.  Over  the  past  decade,  much  of 
the  headquarters  and  field-level  acquisition  guidance  has  been  rescinded,  simplified,  or  re¬ 
duced  in  scope.  As  a  result,  only  minimal  acquisition-related  guidance  remains  in  many  ac¬ 
quisition  areas. 

This  reduction  in  guidance  coincides  with  rising  levels  of  system  complexity  and  the  soft¬ 
ware  contribution  to  overall  system  functionality.  System  development  efforts  face  the  chal¬ 
lenge  of  meeting  aggressive  performance,  cost,  and  schedule  baselines.  At  the  same  time, 
acquisition  leaders  work  to  create  a  flexible  environment  for  acquisition  projects,  while  dras¬ 
tically  decreasing  acquisition  cycle  times  and  improving  credibility.  Increased  complexity, 
demands  for  agile,  adaptable  products,  and  shortened  delivery  timeframes  place  stress  on  ex¬ 
isting  acquisition  practices. 

The  congressional  and  Department  of  Defense  (DoD)-level  guidance  that  remains  in  place 
emphasizes  software  acquisition  process  improvement,  including  the  measurement  of  process 
performance.  The  goal  of  this  guidance  is  to  influence  the  outcome  of  the  acquisition  process, 
delivering  the  right  capabilities  to  operational  users,  on  schedule,  and  at  predictable  costs. 
One  way  to  meet  this  goal  is  through  the  disciplined  application  of  effective  acquisition  proc- 
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esses.  Applying  this  approach,  however,  requires  renewed  dedication  to  defining,  implement¬ 
ing,  measuring,  and  maintaining  the  acquisition  processes  fundamental  to  a  technically  sound 
project. 

The  purpose  of  this  document  is  to  define  effective  and  efficient  acquisition  practices  that 
focus  on  the  activities  performed  by  acquisition  professionals  inside  the  acquisition  program 
office.  The  best  practices  also  address  internal  program  office  activities  that  support  the 
monitoring  and  control  of  external  development  contractors  and  suppliers.  Best  practices 
provide  a  basis  for  acquisition  process  discipline,  while  balancing  the  need  for  agility.  Note, 
however,  that  this  report  identifies  acquisition  practices  that  should  be  implemented,  but  does 
not  prescribe  specific  implementation  approaches. 

1 .2  Acquisition  Processes  and  Practices 

Acquisition  projects  perform  a  number  of  basic  processes  to  achieve  success.  These  processes 
are  described  in  general  terms  to  support  the  numerous  variations  in  application  that  occur  in 
different  acquisition  environments.  Because  variations  in  execution  are  at  the  discretion  of 
the  acquisition  project,  this  module  focuses  on  “what”  should  be  done,  not  “how”  it  is  done. 

Many  acquisition  practices  and  amplifications  in  the  CMMI-AM  module  are  drawn  and 
summarized  from  existing  sources,  including  the  Software  Acquisition  Capability  Maturity 
Model  (SA-CMM),  the  Capability  Maturity  Model  Integration  (CMMI)  framework,  the  Fed¬ 
eral  Aviation  Administration  (FAA)  Integrated  Capability  Maturity  Model  (FAA-iCMM®), 
and  additional  coverage  areas  defined  by  experienced  acquisition  professionals. 

1 .3  Terminology  and  References  to  CMMI  Content 

In  general,  this  module  uses  the  terminology  contained  within  the  CMMI  framework  and 
contains  amplified  text  from  that  framework.  Rather  than  create  a  set  of  recommended  proc¬ 
esses  and  practices  from  scratch,  this  module  utilizes  proven  content  derived  from  the  CMMI 
framework  and  adds  amplifications  specific  to  the  acquisition  process  to  address  the  unique 
facets  of  acquisition. 

Throughout  the  CMMI-AM,  there  are  references  to  the  CMMI  Product  Suite  and  the  CMMI 
framework  to  allow  interested  readers  to  explore  additional  material  about  best  practices.  For 
more  information  about  the  CMMI  framework,  see  the  CMMI  model,  which  contains  all  cur¬ 
rently  published  disciplines,  namely  CMMI  for  Systems  Engineering,  Software  Engineering, 
Integrated  Product  and  Process  Development,  and  Supplier  Sourcing  (CMMI- 
SE/SW/EPPD/SS),  Version  1.1  Continuous  Representation,  released  in  March  2002.  The  con¬ 
tinuous  representation  structures  the  process  areas  in  groupings  related  to  Process  Manage¬ 
ment,  Project  Management,  Engineering,  and  Support.  The  CMMI-AM  mainly  emphasizes 
select  Project  Management,  Engineering,  and  Support  process  areas.  The  Process  Manage¬ 
ment  process  areas  in  the  CMMI  framework  provide  details  on  how  to  define  and  improve 
processes  within  the  context  of  the  organization  in  which  the  acquisition  project  resides.  For 
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more  information  about  using  the  CMMI-AM  in  conjunction  with  the  CMMI  Framework  for 
organizational  process  improvement,  see  the  section  “Improving  Acquisition  Practices”  in  the 
Appendix. 

References  to  CMMI  terminology  should  be  understood  in  both  the  acquisition  and  the  proc¬ 
ess  improvement  contexts.  For  example,  in  the  CMMI  Product  Suite 

•  The  term  project  denotes  a  managed  set  of  interrelated  resources  that  delivers  one  or 
more  products  to  a  customer  or  end-user.  In  the  CMMI-AM,  a  “project”  (or  program, 
depending  on  local  interpretation),  refers  to  the  entire  acquisition  project  or,  perhaps, 
major  subsets  of  the  acquisition  project.  The  scope  of  the  term  is  tailored  to  the 
specific  acquisition. 

•  The  term  organization  is  typically  used  to  denote  an  administrative  structure  in  which 
people  collectively  manage  one  or  more  projects.  Projects  share  a  senior  manager 
and  operate  under  the  same  policies.  Examples  of  acquisition  organizations  include 
larger  or  “super”  program  offices,  product  centers,  acquisition  commands,  Program 
Executive  Officers,  and  Service/Component  acquisition  executives. 

•  The  term  work  product  is  any  artifact  produced  by  a  process. 

•  The  term  product  denotes  a  tangible  output  or  service  that  is  a  result  of  a  process  and 
that  is  intended  for  delivery  to  a  customer  or  end  user.  A  product  is  a  work  product 
that  is  delivered  to  the  customer. 

•  The  term  system  is  not  used  in  the  CMMI  framework,  except  with  respect  to  system 
engineering ;  CMMI  uses  the  term  product  instead.  In  the  CMMI-AM  module,  the 
term  “system”  is  used  in  the  introductory  portion  of  the  module  only. 

•  You  should  decide  how  these  terms  apply  in  your  environment. 
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2  Executive  Questions 


The  questions  included  in  this  section  will  help  acquisition  project  managers  and  program 
executives  determine  if  their  projects  perform  acquisition  activities  in  accordance  with  best 
practices.  The  questions  help  verify  that  best  practices  are  being  employed  and  provide  a 
means  of  gathering  background  information  necessary  to  determine  if  the  products  or  ser¬ 
vices  being  acquired  will  meet  operational  needs. 

The  questions  in  the  tables  below  were  designed  to  facilitate  review  and  improvement  of  the 
acquisition  process  in  organizations.  They  focus  on  whether  or  not  strategy,  planning,  and 
estimating  activities  occur  for  an  acquisition  project.  These  early  activities  determine,  in  large 
part,  the  success  of  an  acquisition  from  the  outset.  The  questions  also  focus  on  risk  identifica¬ 
tion,  management  practices,  capabilities  definition  and  requirements  generation,  and  the  exis¬ 
tence  of  repeatable  processes  that  enable  organizations  to  institutionalize  best  practices.  Note 
that  for  each  question  in  the  left-hand  column,  the  relevant  CMMI-AM  process  areas  are 
listed  in  the  right-hand  column.  The  process  areas  are  described  in  detail  in  Section  3  of  this 
document. 


1.  Acquisition  Strategy 

Questions 

CMMI-AM  Process  Areas 

a.  How  have  you  determined  the  most  appropriate  acquisi¬ 
tion  strategy  for  this  acquisition? 

Project  Planning,  Decision  Analysis  and 
Resolution,  Risk  Management 

b.  How  does  your  selected  acquisition  strategy  mitigate  the 
risks  you  have  identified? 

Project  Planning,  Risk  Management 

c.  Which  stakeholders  were  involved  in  establishing  the  ac¬ 
quisition  strategy? 

Project  Planning,  Integrated  Project 
Management 

2.  Acquisition  Planning 

Questions 

CMMI-AM  Process  Areas 

a.  How  do  your  acquisition  plans  reflect  and  implement  the 
acquisition  strategy? 

Project  Planning,  Integrated  Project 
Management,  Decision  Analysis  and 

Resolution 
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b.  How  did  you  determine  and  document  the  scope  of  the 
program  including  acquisition  project  activities,  supplier  ac¬ 
tivities,  and  other  related  activities  (operational  testing,  user 
activities,  etc.)? 

Project  Planning 

c.  How  did  you  determine  the  size/magnitude  of  the  devel¬ 
opment  effort? 

Project  Planning 

d.  How  did  you  determine  resource  needs  for  each  element 
of  the  project? 

Project  Planning 

e.  How  did  you  determine  a  critical  path? 

Project  Planning,  Integrated  Project 
Management 

f.  How  have  the  plans  been  coordinated  with  relevant  stake¬ 
holders  at  both  the  management  and  working  levels? 

Project  Planning,  Integrated  Project 
Management 

g.  How  will  you  ensure  that  you  have  adequate  staff  with 
the  necessary  experience  and  training  to  execute  your  plans? 

Project  Planning 

h.  How  will  you  ensure  that  the  supplier  has  the  resources 
and  tools  needed  to  complete  the  project? 

Project  Planning,  Solicitation  and  Con¬ 
tract  Monitoring 

i.  How  will  you  ensure  that  the  supplier  has  the  domain  ex¬ 
perience  and  process  capability  needed  to  complete  the  pro¬ 
gram? 

Project  Planning,  Solicitation  and  Con¬ 
tract  Monitoring 

3.  Cost,  Schedule,  and  Performance  Baselines 

CMMI-AM  Process  Areas 

a.  How  have  you  ensured  that  the  cost,  schedule,  and  per¬ 
formance  baselines  are  integrated,  realistic  and  executable? 

Project  Planning,  Integrated  Project 
Management,  Solicitation  and  Contract 
Monitoring 

b.  What  provisions  have  you  made  for  independent  reviews 
of  your  cost,  schedule,  and  performance  baselines? 

Project  Planning,  Integrated  Project 
Management,  Solicitation  and  Contract 
Monitoring,  Requirements  Develop¬ 
ment,  Requirements  Management 

c.  How  have  you  ensured  that  all  the  life  cycle  costs  are  in¬ 
cluded  in  the  baselines  (e.g.,  testing,  training,  sustainment 
and  support)? 

Project  Planning,  Integrated  Project 
Management,  Transition  to  Operations 
and  Support 
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d.  How  do  you  plan  to  track  cost,  schedule,  and  perform¬ 
ance  of  the  project  throughout  its  life  cycle? 


Project  Monitoring  and  Control,  Meas¬ 
urement  and  Analysis 


e.  How  have  you  accommodated  risks  and  engineering 
changes  in  your  baselines? 

Project  Planning,  Risk  Management, 
Requirements  Management 

f.  How  do  you  manage  changes  to  the  baselines? 

Project  Monitoring  and  Control,  Re¬ 
quirements  Management 

g.  How  do  you  evaluate  the  impact  of  changes  in  cost  and 
schedule  on  contractual  development  efforts? 

1 

Project  Monitoring  and  Control,  Solici¬ 
tation  and  Contract  Monitoring,  Re¬ 
quirements  Management 

4.  User  Requirements 

Questions 

CMMI-AM  Process  Areas 

a.  How  do  you  intend  to  manage  users’  involvement  in  the 
requirements  process? 

Project  Planning,  Integrated  Project 
Management,  Requirements  Manage¬ 
ment,  Requirements  Development 

b.  How  do  you  ensure  a  clear  understanding  of  the  user 
needs  by  relevant  stakeholders? 

Requirements  Management,  Require¬ 
ments  Development,  Solicitation  and 
Contract  Monitoring,  Integrated  Project 
Management 

c.  What  role  does  your  organization  play  in  establishing  the 
requirements? 

Requirements  Management,  Require¬ 
ments  Development 

d.  What  is  the  strategy  for  keeping  up  with  the  evolving  op¬ 
erational  environment  (e.g.,  threat,  concept  of  operations, 
technology  readiness)? 

Integrated  Project  Management,  Re¬ 
quirements  Management 

5.  Product  Engineering 

Questions 

CMMI-AM  Process  Areas 

a.  Is  there  a  process  in  place  to  define,  verify,  and  validate 
requirements  and  architectures  for  the  product? 

Requirements  Development 

b.  How  will  the  status  of  development  be  monitored? 

Project  Monitoring  and  Control,  Meas¬ 
urement  and  Analysis,  Solicitation  and 
Contract  Monitoring 
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c.  Describe  your  strategy  for  incorporating  non- 
developmental  products  (e.g.,  commercial  off-the-shelf 
[COTS],  government  off-the-shelf  [GOTS],  reuse,  product 
lines)  into  the  project. 

Project  Planning,  Decision  Analysis  and 
Resolution,  Requirements  Development 

d.  What  percentage  of  the  software  is  planned  to  be  non- 
developmental? 

Project  Planning,  Measurement  and 
Analysis 

e.  How  have  you  determined  that  you  can  achieve  the 
planned  percentage  of  non-developmental  software  use  on 
this  project? 

Project  Planning,  Risk  Management, 
Verification,  Validation,  Decision 
Analysis  and  Resolution 

f.  How  will  you  determine  that  the  planned  non- 
developmental  products  will  provide  the  required  function¬ 
ality  and  performance? 

Measurement  and  Analysis,  Require¬ 
ments  Development,  Verification,  Vali¬ 
dation,  Decision  Analysis  and  Resolu¬ 
tion 

g.  How  will  you  determine  that  the  interfaces  for  non- 
developmental  products  are  defined  and  agreed  to  by  rele¬ 
vant  stakeholders? 

Requirements  Development 

h.  How  have  you  accounted  for  the  effort  required  to  test 
and  integrate  non-developmental  products? 

Requirements  Development,  Verifica¬ 
tion,  Validation 

i.  How  will  the  contractor  demonstrate  the  performance  and 
stability  of  the  development  environment  and  tools? 

Solicitation  and  Contract  Monitoring 

6.  Acquisition  Processes 

CMMl-AM  Process  Areas 

a.  Describe  the  content  and  source  of  your  acquisition  proc¬ 
esses. 

Project  Planning,  Integrated  Project 
Management 

b.  What  mechanism  do  you  use  to  monitor,  control,  and  im¬ 
prove  your  acquisition  processes? 

Project  Monitoring  and  Control,  Meas¬ 
urement  and  Analysis 

c.  How  do  you  know  your  project  is  adhering  to  your  acqui¬ 
sition  processes? 

Project  Monitoring  and  Control 
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7.  Risk  Identification  and  Management 

Questions 

CMMI-AM  Process  Areas  ' 

a.  How  do  you  identify  program  risks? 

Project  Planning,  Risk  Management 

b.  What  risks  have  you  identified  related  to  your  acquisition 
strategy  and  plans? 

Project  Planning,  Risk  Management 

c.  What  are  the  risks  associated  with  cost  and  schedule? 

Project  Planning,  Integrated  Project 
Management,  Risk  Management 

d.  How  have  you  ensured  that  you  understand  the  cost  risk 
of  obtaining  the  required  capability? 

Project  Planning,  Risk  Management, 
Requirements  Development 

e.  What  risks  have  you  identified  related  to  supplier  execu¬ 
tion? 

Project  Planning,  Risk  Management, 
Solicitation  and  Contract  Monitoring 

f.  What  risks  have  you  identified  that  are  outside  your  con¬ 
trol? 

Project  Planning,  Integrated  Project 
Management,  Risk  Management 

g.  How  do  you  assess  (likelihood  and  consequence)  pro¬ 
gram  risks? 

Risk  Management 

h.  How  do  you  monitor  mitigation  efforts  for  identified 
risks? 

Risk  Management 

i.  Describe  the  risk  management  tool(s)  you  employ. 

Project  Planning,  Risk  Management 

j.  Who  is  involved  in  program  risk  assessment  (e.g.,  users, 
supplier,  independent  subject  matter  experts)? 

Integrated  Project  Management,  Risk 
Management 

k.  Explain  how  you  have  built  in  sufficient  reserves  for  risk 
mitigation  and  absorbing  the  impact  of  realized  risks. 

Project  Planning,  Risk  Management 

1.  How  do  you  assess  the  mechanisms  the  supplier  uses  to 
encourage  execution  of  their  organization’s  processes  from 
the  outset  of  the  project? 

Project  Monitoring  and  Control,  Solici¬ 
tation  and  Contract  Monitoring,  Risk 
Management 
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3  Acquisition  Process  Areas 


The  acquisition  process  areas  in  this  section  are  abstracted  from  a  number  of  sources,  princi¬ 
pally  the  CMMI  framework,  the  SA-CMM,  and  the  FAA  iCMM.  Amplifications  related  spe¬ 
cifically  to  acquisition  are  included  to  provide  a  context  for  the  best  practices  used  in  acquisi¬ 
tion  settings. 

The  acquisition  process  areas  represent  a  minimal  set  of  processes  that  cover  the  best  prac¬ 
tices  needed  to  successfully  address  the  entire  acquisition  life  cycle.  Each  acquisition  project 
operates  within  a  unique  environment  that  influences  the  definition  of  its  life  cycle.  The  ac¬ 
quisition  life  cycle,  especially  as  it  applies  to  upgrades  and  modifications,  may  restart  after  a 
cycle  has  been  initiated  and  partially  completed.  For  example,  acquisition  of  a  major  upgrade 
may  be  initiated  for  a  product  that  has  already  been  developed,  fielded,  and  placed  into  opera¬ 
tion.  In  this  case,  the  deployment  of  the  CMMI-AM  could  result  in  the  upgrade  acquisition 
being  considered  a  new  acquisition  life  cycle,  with  complex  implementation  requirements  of 
its  own  that  may  impact  another  acquisition  life  cycle  already  underway.  Or,  in  other  cases, 
the  acquisition  life  cycle  may  continue  throughout  the  product’s  life  cycle  through  disposal. 

In  the  process  areas  listed  below,  goals  are  shown  in  bold-faced  text.  Below  each  goal  are 
numbered  statements  that  reflect  the  recommended  practices. 

3.1  Project  Management  Process  Areas 

Project  management  process  areas  cover  project  management  activities  related  to  planning, 
monitoring,  and  controlling  projects. 

Project  Planning  (PP) 

The  purpose  of  Project  Planning  is  to  establish  and  maintain  plans  that  define  project  activi¬ 
ties. 


For  acquisition,  project  planning  starts  by  setting  the  acquisition  strategy  and  is  followed  by 
planning  the  acquisition  process  in  ever-increasing  levels  of  detail.  The  resulting  plans 
should  be  reviewed  for  consistency  with  the  overall  acquisition  plans.  The  acquirer's  and 
developer's  project  planning  processes  are  continuous  and  the  plans  evolve  to  meet  the 
project's  needs. 

The  acquisition  strategy  relates  the  objectives  for  the  acquisition,  the  constraints,  availability 
of  assets  and  technologies ,  consideration  of  acquisition  methods,  potential  contract  types  and 
terms,  accommodation  of  end  user  considerations,  consideration  of  risk,  and  support  for  the 
program  over  the  life  cycle. 
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If  an  existing  product  is  to  be  replaced  as  part  of  the  acquisition,  the  acquirer  may  be 
required  to  consider  transition  from  operation  and  the  disposal  of  the  existing  product  as  part 
of  the  planning  for  executing  the  new  product.  Any  such  transition  activities  should  be 
included  in  the  project  plan,  and  provisions  for  accommodating  such  specialized 
requirements  should  be  included.  It  may  be  beneficial  to  refer  to  the  Transition  to  Operations 
and  Support  process  area  when  planning. 

Project  Planning  can  best  be  described  by  the  following  goals  and  practices. 

1.  Estimates  of  project  planning  parameters  are  established  and  maintained. 

1.1  Establish  a  top-level  work  breakdown  structure  (WBS)  to  estimate  the  scope  of  the 
project. 

The  WBS  should  include  tasks  for  the  entire  project  to  include  activities  performed  by 
the  acquisition  project  as  well  as  suppliers  and  other  stakeholders  (e.g.,  test 
community,  operational  users)  to  ensure  the  planning  effort  includes  the  scope  for  the 
entire  acquisition. 

1.2  Establish  and  maintain  estimates  of  the  attributes  of  the  work  products  and  tasks. 

Estimates  of  the  attributes  of  the  work  products  and  tasks  are  used  to  bound  the 
budget  and  schedule. 

1.3  Define  the  project  life-cycle  phases  upon  which  to  scope  the  planning  effort. 

Typical  life  cycle  choices  include  single-step  acquisition,  evolutionary  incremental, 
or  evolutionary  spiral.  Include  in  the  planning  the  entire  known  life  cycle  from  user 
needs  through  initial  and  subsequent  upgrades.  The  acquisition  organization  should 
consider  the  full  collection  of  contracts  within  a  project  context  so  that  an  integrated 
approach  results,  rather  than  dealing  with  activities  individually.  This  supports  the 
project  planning  activities  on  the  occasions  when  some  elements  of  the  acquisition  or 
life  cycle  may  be  out  of  the  control  of  a  particular  acquisition  organization. 

1 .4  Estimate  the  project  effort  and  cost  for  the  work  products  and  tasks  based  on 
estimation  rationale. 

In  addition  to  creating  an  estimation  of  the  project  work  products,  the  acquisition 
organization  is  encouraged  to  have  its  estimate  independently  reviewed  by 
individuals  external  to  the  project  to  ensure  that  the  project  estimation  can  be 
validated.  Be  sure  to  include  the  effort  and  cost  supporting  execution  of  the 
acquisition  processes  as  well  as  developing  the  product.  Estimates  of  the  effort  and 
cost  of  work  products  and  tasks  are  used  to  establish  the  overall  project  budget  and 
schedule. 

2.  A  project  plan  is  established  and  maintained  as  the  basis  for  managing  the  project. 

2. 1  Establish  and  maintain  the  project’ s  budget  and  schedule. 

The  acquisition  project’s  budget  and  schedule,  including  the  life-cycle-related 
activities  of  the  acquisition  organization  itself,  the  supplier’s  efforts,  and  those  of  the 
supporting  organizations  and  other  stakeholders,  including  any  contractors  to 
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support  the  acquisition  organization,  should  be  created  and  maintained  for  the 
duration  of  the  project. 

2.2  Identify  and  analyze  project  risks. 

Identify  risks  from  multiple  perspectives  ( e.g .,  acquisition ,  technical ,  management , 
operational,  contractual,  industry,  support,  user,  etc.)  to  ensure  all  project  risks  are 
considered  in  planning  activities. 

2.3  Plan  for  the  management  of  project  data. 

Consider  how  data,  to  include  informal  data  as  well  as  formal  project  data  and 
plans,  will  be  shared  across  all  relevant  stakeholders.  Include  plans  for  managing 
data  within  integrated  teams  and  the  infrastructure  required  to  manage  data  between 
the  supplier,  operational  users,  and  other  relevant  stakeholders.  Decide  which 
program  data  and  plans  require  version  control,  or  more  stringent  configuration 
control,  and  establish  mechanisms  to  ensure  project  data  is  controlled.  Consider  the 
implications  of  controlling  access  to  classified  information  and  sensitive  but 
unclassified  information  (e.g.,  proprietary,  export  controlled,  source  selection 
sensitive)  and  other  access  controlled  data. 

2.4  Plan  for  necessary  resources  to  perform  the  project. 

Plan  for  resources  for  the  acquisition  project  as  well  as  tools  and  infrastructure 
required  during  the  life  of  the  program.  Include  consideration  of  integration  and  test 
facilities. 


2.5  Plan  for  knowledge  and  skills  needed  to  perform  the  project. 

Plan  for  knowledge  and  skills  required  by  the  project  team  to  perform  their  tasks. 
Knowledge  and  skill  requirements  can  derive  from  project  risk.  For  example,  if  the 
project  team  is  acquiring  a  software-intensive  product,  ensure  expertise  in  systems 
and  software  engineering  exists  within  the  project  team,  or  provide  training  for  the 
project  team  in  these  areas.  Include  orientation  and  training  for  project  team  and 
stakeholders  in  acquisition  practices  and  the  domain  knowledge  required  to  execute 
the  project. 

2.6  Plan  the  involvement  of  identified  stakeholders. 

Stakeholders  can  include  operational  users  and  project  participants  from  test  or 
other  support  communities  as  well  as  potential  suppliers.  When  acquiring  products 
that  need  to  interoperate  with  other  products,  plan  for  involvement  of  stakeholders 
from  other  projects  or  communities  to  ensure  the  delivered  product  can  perform  as 
required  in  its  intended  environment. 

2.1  Establish  and  maintain  the  overall  project  plan  content. 

The  overall  project  plan  can  take  on  many  forms  and  may  even  be  found  in  multiple 
plans,  such  as  Acquisition  Strategy,  Single  Acquisition  Management  Plan,  Program 
Management  Plan,  Life-Cycle  Management  Plan,  and  the  Systems  Engineering  Plan. 
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Regardless  of  form,  the  plan  or  plans  should  address  the  acquisition  strategy  as  well 
as  the  cradle-to- grave  considerations  for  the  project  and  product  to  be  acquired. 

3.  Commitments  to  the  project  plan  are  established  and  maintained. 

3.1  Review  all  plans  that  affect  the  project  to  understand  project  commitments. 

The  project  may  have  a  hierarchy  of  plans  ( e.g .,  Risk  Management  Plan ,  Systems 
Engineering  Plan ,  Requirements  Management  Plan).  In  addition ,  stakeholder  plans 
(e.g..  Operational ,  Test ,  Support,  Supplier  plans)  should  be  reviewed  to  ensure 
consistency  among  all  project  participants. 

3.2  Reconcile  the  project  plan  to  reflect  available  and  estimated  resources. 

When  available  resources  (to  include  personnel  facilities,  stakeholders ,  schedule, 
and  funding)  are  inadequate  to  accomplish  the  project,  consider  de -scoping  the  effort 
to  match  available  resources .  When  this  is  not  feasible,  identify  and  mitigate  these 
risks. 

3.3  Obtain  commitment  from  relevant  stakeholders  responsible  for  performing  and 
supporting  plan  execution. 

Major  project  plans  should  be  coordinated  with  and  approved  by  relevant 
stakeholders. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Project  Planning,  see  the  source 
documents  referenced  in  the  bibliography. 


Project  Monitoring  and  Control  (PMC) 

The  purpose  of  Project  Monitoring  and  Control  is  to  provide  an  understanding  of  the  project’s 
progress  so  that  appropriate  corrective  actions  can  be  taken  when  the  project’s  performance 
deviates  significantly  from  the  plan. 

For  acquisition ,  monitoring  and  control  functions  are  directed  within  the  acquisition  project 
early  in  the  process  as  the  acquisition  planning  is  performed  and  the  strategy  is  defined.  As 
the  acquisition  process  unfolds,  monitoring  and  controlling  are  essential  to  ensuring  that 
appropriate  resources  are  being  applied  and  that  acquisition  activities  are  progressing 
according  to  plan.  Project  Monitoring  and  Control  involves  establishing  the  planned  internal 
activities  and  schedule  for  completion  and  then  monitoring  the  status  of  these  activities  and 
work  product  completions  through  measurement  and  analysis  (metrics).  It  is  important  that 
the  acquisition  project  has  internal  processes,  plans,  and  work  products  that  are  monitored 
for  satisfactory  completion  and  progress. 

Included  in  those  internal  items  monitored  should  be  work  product  completion 
(specifications,  plans,  Request  for  Proposal  components,  etc.),  staffing  levels  and 
qualifications  applied '  product  performance  objectives  and  thresholds ,  infrastructure 
readiness  (tools,  networks,  etc.)  and  other  activities  and  products  included  in  project 
planning.  Project  risk  identification  and  mitigation  should  also  be  monitored  for  status. 
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Corrective  action  should  be  applied  when  execution  does  not  match  project  planning  (e.g., 
internal  staffing ,  project  plan  completion  dates ,  draft  and  final  solicitation,  and  contract 
award  milestone  dates). 

If  a  corrective  action  is  required  to  resolve  variances  from  project  plans,  these  actions  should 
be  defined  and  tracked  to  closure . 

After  a  supplier  is  selected  and  an  award  is  made ,  the  role  of  monitoring  and  control 
becomes  twofold,  concerned  with  continuing  to  monitor  and  control  internal  acquisition 
activities  while  also  monitoring  and  controlling  the  progress  of  the  supplier's  execution  under 
the  supplier's  project  plan. 

Project  Monitoring  and  Control  can  best  be  described  by  the  following  goals  and  practices. 

1.  Actual  performance  and  progress  of  the  project  are  monitored  against  the  project 
plan. 

1.1  Monitor  the  actual  values  of  the  project  planning  parameters  against  the  project  plan. 

Monitoring  of  schedule,  budget,  and  acquisition  activity  progress  should  begin  as 
soon  as  a  project  plan  is  established. 

1.2  Monitor  commitments  against  those  identified  in  the  project  plan. 

Commitments  for  resources  that  will  result  in  expenditures  (e.g.,  issued  purchase 
orders,  completed  deliverables  that  have  been  accepted)  should  be  tracked  when 
incurred,  even  prior  to  formal  payment,  to  ensure  that  future  financial  and  legal 
obligations  are  accounted  for  as  soon  as  they  are  incurred. 

1.3  Monitor  risks  against  those  identified  in  the  project  plan. 

The  acquisition  project  should  manage  risks  independent  of  the  contractor's  risk 
management  procedures.  Many  risks  are  the  responsibility  of  the  acquisition  project 
and  may  include  sensitive  information  that  should  not  be  shared  with  the  contractor 
( e.g.,  source  selection  sensitive,  re-competition,  internal  staffing  or  other  risks). 

1 .4  Monitor  the  management  of  project  data  against  the  project  plan. 

1 .5  Monitor  stakeholder  involvement  against  the  project  plan. 

1.6  Periodically  review  the  project’s  progress,  performance,  and  issues. 

1.7  Review  the  accomplishments  and  results  of  the  project  at  selected  project  milestones. 

2.  Corrective  actions  are  managed  to  closure  when  the  project’s  performance  or  re¬ 
sults  deviate  significantly  from  the  plan. 

2. 1  Collect  and  analyze  the  issues  and  determine  the  corrective  actions  necessary  to 
address  the  issues. 

The  acquisition  project  should  manage  issues  and  corrective  actions  independent  of 
the  contractor's  issues  and  corrective  actions  management  procedure.  Many  issues 
and  corrective  actions  are  the  responsibility  of  the  acquisition  project  and  may 
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include  sensitive  information  that  should  not  be  shared  with  the  contractor  ( e.g., 
source  selection  sensitive,  re-competition,  internal  staffing  or  other  issues). 

2.2  Take  corrective  action  on  identified  issues. 

2.3  Manage  corrective  actions  to  closure. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Project  Monitoring  and  Control, 
see  the  source  documents  referenced  in  the  bibliography. 

Solicitation  and  Contract  Monitoring  (SCM) 

The  purpose  of  Solicitation  and  Contract  Monitoring  is  to  prepare  a  solicitation  package  that 
identifies  the  needs  of  a  particular  acquisition,  to  select  a  supplier  that  is  best  capable  of  satis¬ 
fying  those  needs,  and  to  establish  the  process  for  monitoring  the  supplier  for  the  duration  of 
the  contract. 

For  acquisition,  the  solicitation  must  comply  with  the  applicable  federal,  departmental,  and 
service  acquisition  regulations  and  policies.  The  solicitation  should  address  activities 
appropriate  to  the  product  domain  or  acquisition  environment  (e.g.,  supplier  process 
evaluations,  operational  safety,  suitability,  and  effectiveness,  certifications,  architecture 
evaluations,  and  interoperability ).  The  representatives  responsible  for  these  activities  within 
the  project  or  stakeholder  organizations  should  be  consulted  for  proper  inclusion  of  those 
activities  into  the  solicitation  and  contract  monitoring  process.  The  solicitation  practices 
apply  equally  to  initial  contractual  actions  and  subsequent  change  orders,  task  orders,  etc. 

The  Solicitation  and  Contract  Monitoring  process  area  creates  a  proactive  environment  that 
enables  the  acquirer  to  initialize  and  adapt  the  relationship  with  the  supplier  over  the  duration 
of  that  relationship  for  the  successful  execution  of  the  project.  In  addition,  it  encourages  crea¬ 
tion  of  a  contract  that  allows  the  acquirer  to  execute  its  monitoring  and  control  of  supplier 
activities  using  other  process  areas,  such  as  Project  Monitoring  and  Control.  This  encour¬ 
agement  may  include  levying  a  contractual  requirement  on  the  supplier  to  create  a  project 
plan  that  will  successfully  execute  the  contract,  to  define  and  execute  the  processes  needed  to 
achieve  success,  and  to  commit  to  execute  their  plan  as  it  evolves  during  contract  execution. 

The  Solicitation  and  Contract  Monitoring  process  area  involves  planning  for  and  performing 
the  practices  necessary  to  develop  and  issue  a  solicitation  package,  preparing  for  the  evalua¬ 
tion  of  responses,  conducting  an  evaluation,  conducting  supporting  negotiations,  making  rec¬ 
ommendations  for  award  of  the  contract,  and  overseeing  the  execution  phase  to  ensure  the 
needs  of  the  acquisition  are  met. 

The  acquirer  and  supplier  establish  and  maintain  a  mutual  understanding  through  effective, 
timely,  and  appropriate  communication.  The  acquirer  should  clearly  identify  and  prioritize  its 
needs  and  expectations,  as  well  as  its  suppliers’  capabilities.  The  acquirer  works  closely  with 
suppliers  to  achieve  a  mutual  understanding  of  product  requirements,  responsibilities,  and 
processes  that  are  applied  to  achieve  project  objectives. 
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Solicitation  and  Contract  Monitoring  can  best  be  described  by  the  following  goals  and  prac¬ 
tices. 


1.  The  project  is  prepared  to  conduct  the  solicitation. 

LI  Designate  a  selection  official  responsible  for  making  the  selection  decision. 

1.2  Establish  and  maintain  a  solicitation  package  that  includes  the  needs  of  the 
acquisition  and  corresponding  proposal  evaluation  criteria. 

For  task  orders  or  contractual  changes  against  an  existing  contract ,  ensure  the 
acquisition  project  has  documented  evaluation  criteria  against  which  to  evaluate  the 
proposed  changes  from  the  contractor. 

Define  the  proposal  content  that  the  offerors  must  submit  with  their  response. 
Examples  include: 

The  requirement  to  provide  evidence  of  existing  organizational  processes  upon 
which  the  project's  processes  will  be  based ,  and  the  commitment  to  execute  those 
processes  from  project  inception; 

The  requirement  to  reflect  in  the  proposed  contractual  documents  such  as  the 
Statement  of  Work  (SOW),  Integrated  Master  Plan  (IMP),  Integrated  Master 
Schedule  (IMS)  and  Software  Development  Plan  (SDP)  the  processes,  tasks  and 
activities  characteristic  of  the  proposed  development  approach; 

The  requirement  to  describe  how  the  proposed  approach  ( e.g.,  SOW,  IMP,  IMS, 
SDP  or  other  contractual  documents)  demonstrates  a  commitment  to  execute  the 
project  using  the  processes  and  methods  proposed  from  project  inception .  Require 
offerors  to  provide  evidence  of  a  mechanism  to  encourage  and  monitor  execution 
of  organizational  processes  at  project  start  up.  Require  offerors  to  describe 
measurements  that  provide  the  project  team  visibility  into  the  supplier  ’s  process 
adherence; 

The  requirement  to  describe  how  the  proposed  approach  demonstrates  high 
confidence  that  the  size  and  complexity  of  the  development  and  integration  effort 
is  understood,  the  effort  and  schedule  necessary  to  develop  the  required  products 
are  estimated  with  high  confidence,  and  that  the  proposed  development  effort  is 
compatible  with  and  can  be  completed  within  the  proposed  funding  and  schedule; 

Plans  appropriate  to  the  scope  and  content  of  the  program  (e.g.,  Integrated 
Management  Plan,  Systems  Engineering  Plan,  Software  Development  Plan,  Risk 
Management  Plan); 

Identification  of  the  measurements  (to  include  development  progress  measures)  to 
be  used  in  the  project  and  made  available  to  the  project  office; 

A  description  of  the  offeror’s  planned  use  of  COTS  or  re-use  of  previously 
developed  hardware  or  software  components,  including  non-deliverable 
components.  This  should  include  identification  of  any  limitation  on  data  rights 
and  rationale  for  the  offeror's  confidence  that  the  levels  of  COTS  and  re-use  can 
be  achieved; 
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An  approach  to  provide  visibility  for  development  task  progress  and  costs  at  a 
level  appropriate  for  the  type  of  contract  and  commensurate  with  the  degree  of 
risk  related  to  the  acquisition ; 

Identification  of  the  work  to  be  performed  by  lower-level  suppliers; 

Proposed  tasks  and  activities  to  support  product  verification ,  validation ,  and 
transition  to  operations  and  support; 

Technical  non-technical,  and  product  verification  requirements  to  be  satisfied  by 
the  supplier; 

Deliverables  that  provide  the  acquisition  project  sufficient  data  to  allow 
verification  and  validation  of  acquired  products; 

Requirements  to  ensure  that  the  supplier  supports  each  of  the  acquisition  projects 
verification  and  validation  activities;  and 

Requirements  for  the  supplier  to  establish  a  corrective  action  system  that  includes 
a  change  control  process  for  rework  and  reevaluation . 

The  acquisition  organization  should  request  evidence  of  adherence  to  the  supplier 
organization's  mechanism  for  project  start  up  in  accordance  with  their  defined 
processes. 

1.3  Establish  and  maintain  independently  reviewed  cost  and  schedule  estimates  for  the 
products  to  be  acquired. 

To  ensure  objectivity  and  realism,  cost  and  schedule  estimates  should  be  reviewed  by 
individuals  independent  of  the  acquisition  project  team  and  supplier's  team . 
Representatives  from  the  functional  or  " Home  Office"  organizations  at  the 
acquisition  organizations,  such  as  finance  and  engineering ,  can  support  these  efforts . 

1.4  Validate  the  solicitation  package  with  end  users  and  potential  offerors  to  ensure  the 
approach  and  cost  and  schedule  estimates  are  realistic  and  can  reasonably  lead  to  a 
usable  product. 

In  a  competitive  environment,  ensure  all  potential  offerors  have  equal  access  and 
opportunity  to  provide  feedback  on  the  solicitation  package.  Provide  the  opportunity 
for  the  selected  suppliers  and  end  users  to  clarify  points  of  ambiguity  in  the  set  of 
required  capabilities  as  well  as  any  disconnects  or  concerns  with  the  proposed 
solution.  In  a  sole  source  or  change  order  environment ,  make  sure  relevant 
stakeholders  understand  the  intent  of  the  effort  or  changes  before  placing  the 
additional  work  on  contract . 

2.  Suppliers  are  selected  based  on  the  solicitation  package. 

2. 1  Evaluate  proposals  according  to  the  documented  evaluation  criteria. 

The  criteria  are  used  to  evaluate  the  offerors'  technical  approach  as  well  as  their 
management  practices ,  sufficiency  of  plans,  process  capability  in  key  program  risk 
areas ,  relevant  domain  experience,  cost,  schedule ,  and  past  performance . 
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2.2  Use  proposal  evaluation  results  as  a  basis  to  support  selection  decisions. 

3.  Contracts  are  issued  based  on  the  needs  of  the  acquisition  and  the  suppliers’  pro¬ 
posed  approaches. 

3.1  Establish  and  maintain  a  mutual  understanding  of  the  contract  with  selected  suppliers 
and  end  users  based  on  the  acquisition  needs  and  the  suppliers’  proposed  approaches. 

As  points  of  clarification  and  ambiguities  continue  to  arise  after  contract  award [ 
ensure  the  mutual  understanding  is  revised  and  maintained  through  the  life  of  the 
project.  Ensure  that  the  supplier  makes  a  contractual  commitment  to  execute  its 
proposed  processes. 

3.2  Establish  and  maintain  communication  processes  and  procedures  with  suppliers  that 
emphasize  the  needs,  expectations,  and  measures  of  effectiveness  to  be  used 
throughout  the  acquisition. 

The  acquisition  project  is  responsible  for  establishing  and  maintaining  the  ground 
rules  for  supplier  communication ,  documenting  decisions ,  and  conflict  resolution 
through  the  life  of  the  project  The  acquisition  project  facilitates  this  with  relevant 
project  stakeholders.  Specific  roles  and  responsibilities  of  relevant  project 
stakeholders  for  interaction  with  or  direction  of  the  suppliers  need  to  be  defined, 
coordinated,  and  adhered  to. 

After  the  contract  is  awarded,  the  acquisition  project  should  verify  that  the  supplier 
is  effectively  executing  its  organization’s  processes. 

4.  Work  is  coordinated  with  suppliers  to  ensure  the  contract  is  executed  properly. 

4. 1  Monitor  and  evaluate  selected  processes  used  by  the  supplier  based  on  the  supplier’s 
documented  processes. 

The  supplier’s  plans  and  processes  are  used  as  the  basis  for  monitoring  its  activities. 
The  acquisition  project  is  responsible  for  ensuring  the  supplier’s  “as  implemented” 
processes  address  the  needs  of  the  project.  The  acquisition  project  should  verify  that 
the  supplier’s  processes  are  executed  from  project  inception. 

4.2  Evaluate  selected  supplier  work  products  based  on  documented  evaluation  criteria. 

The  acquisition  project  must  decide  based  on  risk  and  available  resources  which 
products  will  be  evaluated.  This  may  include  interim  work  products  as  well  as 
delivered  products.  >  • 

4.3  Revise  the  supplier  agreement  or  relationship,  as  appropriate,  to  reflect  changes  in 
conditions. 

When  the  supplier’s  processes  or  products  fail  to  meet  established  criteria ,  the 
acquisition  project  may  decide  to  apply  contractual  remedies.  While  monitoring 
process  adherence  and  product  development,  the  acquisition  project  may  find 
contractual  requirements  that  are  no  longer  optimal  based  on  the  supplier’s  progress 
or  environment  changes.  Examples  include  overly  burdensome  documentation, 
reporting  requirements,  or  evolving  process  requirements  when  warranted  by 
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demonstrated  performance  on  the  contract  In  these  cases ,  the  acquisition  project 
should  be  flexible  to  facilitate  achieving  efficient  processes  that  still  meet  the  needs 
of  the  overall  project.  Examples  where  flexibility  may  be  warranted  based  on 
demonstrated  performance  on  the  contract  include  overly  burdensome 
documentation ,  reporting  requirements ,  and  evolving  process  requirements . 

For  more  extensive  treatment  of  the  goals  and  practices  of  Solicitation  and  Contract  Monitor¬ 
ing,  see  the  source  documents  referenced  in  the  bibliography. 


Integrated  Project  Management  (IPM) 

The  purpose  of  Integrated  Project  Management  is  to  establish  and  manage  the  project  and  the 
involvement  of  the  relevant  stakeholders  according  to  an  integrated  and  defined  process  that 
is  tailored  from  the  organization’s  set  of  standard  processes. 

For  acquisition,  Integrated  Project  Management  involves  establishing  project  management 
processes  consistent  with  and  tailored  from  the  organization’s  standard  processes.  This 
includes  higher  level  acquisition  guidance,  regulations,  instructions,  and  local  practices 
established  to  be  used  across  various  projects  in  the  local  organization.  Establishing  an 
integrated  project  management  process  that  incorporates  and  involves  relevant  stakeholders 
(e.g.,  executive  level  acquisition  offices,  users,  test  organizations,  developers,  and  associated 
government  support  organizations)  is  critical  to  the  success  of  the  project.  This  defined 
project  management  process  is  typically  defined  in  an  overall  project  management  plan  or 
equivalent  document. 

The  integrated  project  management  process  needs  to  involve  and  integrate  all  relevant 
acquisition,  development,  support,  and  operational  activities.  Depending  on  the  size  of  the 
project,  the  size  of  the  coordination  efforts  can  be  significant. 

Wormed  interfaces  among  project  stakeholders  take  the  form  of  memorandums  of 
understanding  (MOUs),  memorandums  of  agreements  (MOAs),  contractual  commitments, 
associate  contractor  agreements,  and  similar  documents,  depending  on  the  nature  of  the 
interfaces  and  involved  stakeholders. 

Integrated  Project  Management  is  best  described  by  the  following  goals  and  practices. 

1.  The  project  is  conducted  using  a  defined  process  that  is  tailored  from  the  organiza¬ 
tion’s  set  of  standard  processes. 

it  is  possible  that  an  organization  has  not  established  a  standard  set  of  processes.  If  so, 
the  project  should  define  its  own  processes  appropriate  to  its  need. 

1 . 1  Establish  and  maintain  the  project’ s  defined  process. 

Often,  the  defined  process  for  a  project  is  developed  by  tailoring  and  integrating 
higher  level  organizational  guidance.  For  example,  the  DoD  Acquisition  Framework 
(http://akss.dau.mil/dag/)  describes  a  series  of  requirements  and  tailoring  guidelines 
for  acquisition  projects.  This  guidance,  in  conjunction  with  lower  level  guidance  at 
the  Service,  Component,  or  other  level,  would  be  used  by  a  project  to  establish  the 
process  to  be  used  to  acquire  the  project’s  unique  product  or  service.  Where  no 
organizational  process  exists,  the  project  should  develop  defined  processes  itself 
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1.2  Use  the  organizational  process  assets  and  measurement  repository  for  estimating  and 
planning  the  project’s  activities. 

When  available,  use  the  results  of  previous  planning  and  execution  activities  as 
predictors  of  the  relative  scope  and  size  of  the  effort  being  estimated  for  the 
acquisition. 

1.3  Integrate  the  project  plan  and  the  other  plans  that  affect  the  project  to  describe  the 
project’s  defined  process. 

Tiered  plans  are  often  effective  for  large  programs. 

1.4  Manage  the  project  using  the  project  plan,  the  other  plans  that  affect  the  project,  and 
the  project’s  defined  process. 

1.5  Contribute  work  products,  measures,  and  documented  experiences  to  the 
organizational  process  assets. 

If  a  repository  of  previous  information  exists  at  the  start  of  the  project,  consider 
retaining  the  project’s  estimates  and  actual  results  for  use  in  estimating  future 
projects. 

2.  Coordination  and  collaboration  of  the  project  with  relevant  stakeholders  are  con¬ 
ducted. 

2. 1  Manage  the  involvement  of  the  relevant  stakeholders  in  the  project. 

The  acquisition  organization  should  encourage  stakeholder  involvement  and  manage 
their  activities,  ensuring  that  stakeholder  coordination  and  cooperation  are 
maximized  to  the  extent  possible,  -f  •; 

2.2  Participate  with  relevant  stakeholders  to  identify,  negotiate,  and  track  critical 
dependencies. 

Stakeholder  activities  that  include  dependencies  that  are  critical  to  the  project  should 
be  negotiated  with  the  stakeholders  to  obtain  commitment  to  perform.  The  critical 
dependencies  should  be  identified  in  the  project  plan  so  those  activities  can  be 
monitored  and  controlled  relative  to  the  dependent  activities. 

2.3  Resolve  issues  with  relevant  stakeholders. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Integrated  Project  Management, 
see  the  source  documents  referenced  in  the  bibliography. 


Risk  Management  (RSKM) 

The  purpose  of  Risk  Management  is  to  identify  potential  problems  before  they  occur,  so  that 
risk-handling  activities  may  be  planned  and  invoked  as  needed  across  the  life  of  the  product 
or  project  to  mitigate  adverse  impacts  on  achieving  objectives. 
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For  acquisition ,  risk  identification  and  estimation  of  probability  of  occurrence  and  impact, 
particularly  for  those  risks  involved  in  meeting  performance  requirements ,  schedules ,  and 
cost  targets,  largely  determines  the  acquisition  strategy.  The  acquirer  has  a  dual  role:  first,  in 
assessing  and  managing  overall  project  risks  for  the  duration  of  the  project,  and  second ,  in 
assessing  and  managing  risks  associated  with  the  performance  of  the  supplier.  As  the 
acquisition  progresses  to  the  selection  of  a  supplier,  the  risk  specific  to  the  supplier's 
technical  and  management  approach  then  becomes  important  to  the  success  of  the 
acquisition . 

The  particular  risks  associated  with  conducting  the  project  using  integrated  teams  should  be 
considered,  such  as  risks  associated  with  loss  of  inter-team  or  intra-team  coordination . 

Risk  Management  can  best  be  described  by  the  following  goals  and  practices. 

1.  Preparation  for  risk  management  is  conducted. 

1.1  Determine  risk  sources  and  categories. 

Acquisition  organizations  should  identify  and  categorize  risks  and  risk  sources  for 
the  project  initially  and  refine  those  risks  and  categories  over  time  (e.g.,  schedule , 
cost ,  contractor  execution,  technology  readiness,  issues  outside  control  of  acquisition 
organization). 

1.2  Define  the  parameters  used  to  analyze  and  categorize  risks  and  the  parameters  used 
to  control  the  risk  management  effort. 

Acquisition  organizations  should  record  the  parameters  used  to  analyze  and 
categorize  risks  so  that  they  are  available  throughout  the  project  period  for  reference 
when  circumstances  change  over  time.  In  this  way,  risks  can  easily  be  re-categorized 
and  analyzed  relative  to  the  original  information  when  changes  occur. 

1.3  Establish  and  maintain  the  strategy  to  be  used  for  risk  management. 

2.  Risks  are  identified  and  analyzed  to  determine  their  relative  importance. 

2. 1  Identify  and  document  the  risks. 

2.2  Evaluate  and  categorize  each  identified  risk  using  the  defined  risk  categories  and 
parameters,  and  determine  its  relative  priority. 

3.  Risks  are  handled  and  mitigated,  where  appropriate,  to  reduce  adverse  impacts  on 
achieving  objectives. 

3.1  Develop  a  risk  mitigation  plan  for  the  most  important  risks  to  the  project,  as  defined 
by  the  risk  management  strategy. 

3.2  Monitor  the  status  of  each  risk  periodically  and  implement  the  risk  mitigation  plan  as 
appropriate. 

Risks  should  be  continually  monitored  and,  when  warranted,  the  mitigation  plan 
should  be  adjusted  to  adapt  for  change.  When  the  situation  requires  action, 
mitigation  actions  should  be  executed  promptly  based  upon  the  mitigation  plan. 
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For  more  extensive  treatment  of  the  goals  and  practices  of  Risk  Management,  see  the  source 
documents  referenced  in  the  bibliography. 


3.2  Engineering  Process  Areas 

The  engineering  process  areas  establish  a  consistent  set  of  requirements  that  are  derived  from 
stakeholder  needs  and  operational  capability  statements  so  that  work  products  developed  in¬ 
ternally  by  the  acquirer  and  work  products  and  delivered  products  from  the  suppliers  are 
proven  to  successfully  satisfy  end  user  needs  and  provide  operational  capabilities. 


Requirements  Development  (RD) 

The  purpose  of  Requirements  Development  is  to  produce  and  analyze  customer,  product,  and 
product-component  requirements. 

For  acquisition,  Requirements  Development  has  two  contexts.  The  first  context  is  the 
amalgamation  and  coordination  of  the  operational  requirements  (i.e.,  customer  requirements) 
into  a  set  of  requirements  that  will  define  the  scope  and  direction  of  the  acquisition.  The 
second  context  is  the  allocation  and  extension  of  the  customer  requirements  and  additional 
acquirer  requirements  (e.g.,  product  characteristics,  design  requirements,  architecture 
requirements )  that  become  the  basis  of  the  product  and  component  requirements  derived  and 
developed  by  the  supplier’s  organization. 

There  is  a  continuous  iteration  of  requirements  down  through  the  multiple  tiers  of 
requirements  documents  associated  with  the  components  of  a  product.  For  example, 
requirements  flow  from  the  stakeholders  to  the  top  level  down  to  multiple  lower  levels  and 
eventually  to  either  hardware  or  software  component  levels.  The  responsibility  for  developing 
requirements  down  through  the  levels  is  generally  split  between  the  acquirer  and  the  supplier. 
The  acquirer  is  generally  responsible  for  the  higher  levels,  starting  with  operational 
requirements,  and  the  supplier  is  generally  responsible  for  lower  levels.  The  division  of 
responsibilities  between  the  acquirer  and  supplier  is  determined  by  each  project . 

The  acquirer  is  responsible  for  defining  and  baselining  the  requirements  levels  under  its 
control  and  also  monitoring  the  supplier  definition  of  the  lower  level  requirements. 

When  acquiring  services  instead  of  products,  the  same  requirements  process  is  used  to  define 
high-level  operational  needs  and  to  allocate  those  needs  to  lower  level  components  of  the 
service  to  ensure  the  resulting  service  meets  the  original  intent. 

Requirements  Development  can  best  be  described  by  the  following  goals  and  practices. 

1.  Stakeholder  needs,  expectations,  constraints,  and  interfaces  are  collected  and  trans¬ 
lated  into  customer  requirements. 

1.1  Elicit  stakeholder  needs,  expectations,  constraints,  and  interfaces  for  all  phases  of  the 
product  life  cycle. 

This  includes  review ;  coordination,  and  formalization  with  the  user  of  top  level 
operational  needs  and  requirements. 
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1.2  Transform  stakeholder  needs,  expectations,  constraints,  and  interfaces  into  customer 
requirements. 

This  includes  the  transformation  of  the  top  level  user  requirements  into  engineering 
oriented  requirements  that  are  typically  included  in  a  solicitation.  Requirements  also 
include  non-functional  requirements  and  other  attributes  such  as  evolvability, 
maintainability,  and  re-usability ,  which  can  drive  the  definition  of  the  product 
requirements  and  architecture. 

This  includes  definition  of  high-level  interface  requirements  in  the  system  of  systems 
and  interoperability  domains. 

2.  Customer  requirements  are  refined  and  elaborated  to  develop  product  and  product- 
component  requirements. 

2. 1  Establish  and  maintain  product  and  product-component  requirements,  which  are 
based  on  the  customer  requirements. 

The  level  of  involvement  of  the  acquirer  in  allocating  system-level  requirements  to 
lower  level  subsystems  and  components  will  vary  depending  on  the  acquisition 
environment. 

2.2  Allocate  the  requirements  for  each  product  component. 

As  each  level  of  requirements  is  defined  there  is  an  iterative  process  of  allocation, 
high-level  design,  and  requirements  definition  (for  the  next-lower  level).  Beyond  the 
level  of  the  architecture  at  which  this  responsibility  has  been  assigned  to  the  supplier, 
it  is  the  acquirer's  role  to  oversee  the  adequacy  of  the  supplier's  process  and  the 
resultant  flow-down  and  definition  of  the  lower  level  requirements. 

2.3  Identify  interface  requirements. 

Requirements  include  not  only  the  classical  functional  and  performance 
requirements ,  but  also  interface  requirements,  whether  they  are  contained  in  separate 
interface  specifications  or  within  the  requirements  specifications. 

3.  The  requirements  are  analyzed  and  validated,  and  a  definition  of  required  function¬ 
ality  is  developed. 

3.1  Establish  and  maintain  operational  concepts  and  associated  scenarios. 

“  Concepts  of  Operations  Documents"  or  similar  documents  that  define  the  intended 
usage  concepts  and  environments  are  useful  in  developing  requirements  and  designs 
that  will  ultimately  satisfy  the  user's  operational  needs. 

3.2  Establish  and  maintain  a  definition  of  required  functionality. 

Formal  definition  and  maintenance  of  the  user's  top  level  operational  requirements  is 
effective  in  scoping  and  managing  overall  performance  expectations  throughout  the 
development. 

3.3  Analyze  requirements  to  ensure  that  they  are  necessary  and  sufficient. 
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3.4  Analyze  requirements  to  balance  stakeholder  needs  and  constraints. 

Balance  stakeholder  needs  against  constraints  such  as  development  cost  and 
schedule  or  operational  and  support  considerations . 

3.5  Validate  requirements  to  ensure  the  resulting  product  will  perform  as  intended  in  the 
user’s  environment  using  multiple  techniques  as  appropriate. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Requirements  Development,  see 
the  source  documents  referenced  in  the  bibliography. 


Requirements  Management  (REQM) 

The  purpose  of  Requirements  Management  is  to  manage  the  requirements  of  the  project's 
products  and  product  components  and  to  identify  inconsistencies  between  those  requirements 
and  the  project's  plans  and  work  products. 

For  acquisition ,  requirements  management  is  applied  to  the  requirements  that  are  received 
from  the  requirements  development  process.  During  the  acquisition,  requirements 
management  includes  the  direct  management  of  acquirer-controlled  requirements  and 
oversight  of  supplier  requirements  management.  Requirements  are  managed  and  maintained 
with  discipline  so  that  changes  are  not  executed  without  recognizing  the  impact  to  the 
project. 

Requirements  Management  does  not  end  with  the  selection  of  a  supplier  and  an  award.  The 
acquisition  project  continues  to  manage  high-level  requirements,  including  changes,  while 
the  selected  supplier  manages  the  lower  level  requirements. 

Requirements  Management  can  best  be  described  by  the  following  goals  and  practices. 

1.  Requirements  are  managed  and  inconsistencies  with  project  plans  and  work  prod¬ 
ucts  are  identified. 

1.1  Develop  an  understanding  with  the  requirements  providers  on  the  meaning  of  the 
requirements. 

The  acquirer  should  define  “authorized”  requirements  providers  and  an  approved 
path  by  which  requirements  are  provided  to  the  supplier.  This  definition  prevents 
suppliers  from  receiving  requirements  changes  from  unauthorized  sources  that  are 
outside  the  flow  of  the  acquirer's  established  requirements  management  process. 

1.2  Obtain  commitment  to  the  requirements  from  the  project  participants. 

Commitment  to  the  requirements  by  the  project  participants  includes  having 
coordinated  and  approved  documents  that  define  requirements. 

1.3  Manage  changes  to  the  requirements  as  they  evolve  during  the  project. 

Each  change  to  a  controlled  requirement  should  be  assessed  for  impact  to  the 
project  s  performance,  cost,  and  schedule  baselines  and  to  project  risk.  The  existing 
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cost ,  schedule ,  awe?  performance  baselines  should  be  changed ,  as  requiredy  to 
accommodate  the  requirements  change. 

1.4  Maintain  bidirectional  traceability  among  the  requirements  and  the  project  plans  and 
work  products. 

Bidirectional  traceability  ensures  that  all  higher  level  requirements  are  accounted  for 
by  the  totality  of  the  lower  level  requirements .  It  also  ensures  that  lower  level 
requirements  are  tied  to  a  parent  requirement  to  prevent  orphan  requirements  at  the 
lower  levels.  Bidirectional  traceability  also  supports  requirements  change  impact 
analysis  when  either  high  or  lower  level  requirements  change. 

1.5  Identify  inconsistencies  between  the  project  plans  and  work  products  and  the 
requirements. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Requirements  Management,  see 
the  source  documents  referenced  in  the  bibliography. 


Verification  (VER) 

The  purpose  of  Verification  is  to  ensure  that  selected  work  products  meet  their  specified  re¬ 
quirements. 

For  acquisition,  verification  involves  ensuring  that  the  evolving  work  products  of  the 
acquisition  project  meet  specified  requirements  for  those  products.  The  acquisition  project 
should  ensure  that  a  proper  verification  environment  exists  and  that  it  selects  work  products 
to  evaluate  based  on  documented  criteria.  Peer  reviews  are  intended  to  be  used  for  work 
products  developed  by  the  acquisition  project. 

The  acquisition  project  is  also  responsible  for  ensuring  that  the  supplier  uses  appropriate 
methods  to  verify  its  work  products.  In  this  context,  the  test  community  is  a  major  stakeholder, 
including  participation  in  up-front  planning  through  final-product  acceptance.  The  supplier 
and/or  the  test  community  may  perform  many  of  these  practices,  with  the  acquisition  project 
facilitating  the  correction  of  deficiencies  or  enhancements  by  the  supplier  or  follow-on 
maintenance  organization.  It  is  important  that  the  acquirer  define  at  the  outset  the  degree  to 
which  verification  is  required  both  early  in  the  definition  of  the  project  and  later  when  the 
products  are  received. 

Verifications  of  the  evolving  products  by  both  the  supplier  and  project  team  are  routinely 
conducted  throughout  the  entire  contract  performance  period,  and  results  are  analyzed  to 
determine  acceptability  of  the  products.  Acquisition  project  verification  activities  should  be 
designed  to  reduce  interference  with  supplier  and  test  community  performed  activities  and  to 
reduce  duplication  of  the  verification  efforts. 

Verification  can  best  be  described  by  the  following  goals  and  practices. 

1.  Preparation  for  verification  is  conducted. 

1.1  Select  the  work  products  to  be  verified  and  the  verification  methods  that  will  be  used 
for  each. 
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Work  products  can  be  developed  by  either  the  acquisition  project  or  the  supplier. 

Peer  reviews  are  one  of  the  methods  used  to  verify  work  products  produced  by  the 
acquisition  project.  Other  methods  should  be  selected  when  verifying  work  products 
from  the  supplier.  Examples  of  these  other  methods  include  demonstration , 
inspection ,  and  actual  testing. 

1.2  Establish  and  maintain  the  environment  needed  to  support  verification. 

The  acquisition  project  should  provide  an  adequate  environment  to  carry  out  its 
verification  activities. 

1.3  Establish  and  maintain  verification  procedures  and  criteria  for  the  selected  work 
products. 

2.  Peer  reviews  are  performed  on  selected  work  products. 

A  peer  review  is  a  method  for  conducting  verification  of  work  products  that  has  had  great 
success  in  detecting  defects ,  especially  in  documents  for  requirements  and  design.  The 
intent  is  for  the  acquisition  project  to  use  peer  reviews  on  selected  products  (e.g., 
solicitation  documents,  system  engineering  plans,  test  plans)  they  produce  internally  to 
find  and  remove  defects  and  to  ensure  compliance  to  acquisition  standards.  Many  work 
products  produced  by  the  acquisition  project  set  the  stage  for  the  program  success  and 
are  critical  to  the  supplier  ’s  performance.  The  supplier  typically  uses  peer  reviews 
internally  on  selected  interim  work  products  during  development,  but  the  acquirer  should 
not  rely  solely  on  these  results. 

2. 1  Prepare  for  peer  reviews  of  selected  work  products. 

2.2  Conduct  peer  reviews  on  selected  work  products  and  identify  issues  resulting  from 
the  peer  review. 

2.3  Analyze  data  about  preparation,  conduct,  and  results  of  the  peer  reviews. 

3.  Selected  work  products  are  verified  against  their  specified  requirements. 

3. 1  Perform  verification  on  the  selected  work  products. 

3.2  Analyze  the  results  of  all  verification  activities  and  identify  corrective  action. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Verification,  see  the  source  docu¬ 
ments  referenced  in  the  bibliography. 


Validation  (VAL) 

The  purpose  of  Validation  is  to  demonstrate  that  a  product  or  product  component  fulfills  its 
intended  use  when  placed  in  its  intended  environment. 

Validation  activities  can  be  applied  to  all  aspects  of  the  product  in  any  of  its  intended 
environments,  such  as  operation,  training,  manufacturing,  maintenance,  and  support 
services.  The  methods  employed  to  accomplish  validation  can  be  applied  to  work  products  as 
well  as  to  the  product  and  product  components.  The  work  products  (e.g.,  requirements, 
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designs,  prototypes )  should  be  selected  for  validation  based  on  which  are  the  best  predictors 
of  how  well  the  delivered  end  product  and  product  components  will  satisfy  user  needs. 

For  acquisition,  validation  involves  ensuring  that  the  evolving  acquisition  work  products 
(e.g.,  RFPs,  SCWs,  plans)  meet  the  acquisition  project’s  needs.  Validation  activities  are 
normally  performed  early  and  continuously  throughout  the  acquisition  life  cycle.  The 
acquirer  also  uses  validation  processes  to  ensure  that  the  product  or  service  received  from 
the  supplier  will  fulfill  its  intended  use.  In  this  context,  the  test  community  is  a  major 
stakeholder,  participating  in  up-front  planning  through  final-product  acceptance.  The 
supplier  and/or  the  test  community  may  perform  many  of  the  validation  practices,  with  the 
acquisition  project  facilitating  the  correction  of  deficiencies  or  enhancements  by  the  supplier 
or  follow-on  maintenance  organization. 

Validation  involves  the  development  of  requirements  for  the  validation  approach,  including 
acceptance  criteria,  which  are  incorporated  into  both  the  solicitation  package  and  the  con¬ 
tract.  Validations  of  the  evolving  products  by  both  the  supplier  and  project  are  routinely  con¬ 
ducted  throughout  the  entire  contract  performance  period  and  results  are  analyzed  to  deter¬ 
mine  acceptability  of  the  products.  Project  validation  activities  should  be  designed  to  reduce 
interference  with  supplier  and  test  community-performed  activities  and  to  reduce  duplication 
of  the  validation  efforts.  Validation  processes  support  establishing  and  validating  require¬ 
ments.  See  the  Requirements  Development  process  area  for  more  information. 

Validation  can  best  be  described  by  the  following  goals  and  practices. 

1.  Preparation  for  validation  is  conducted. 

1 . 1  Select  products  and  product  components  to  be  validated  and  the  validation  methods 
that  will  be  used  for  each. 

It  is  important  that  the  acquirer  define  at  the  outset  the  degree  to  which  validation  is 
required  both  early  in  the  project  (e.g.,  requirements  validation  activities)  and  later 
when  the  end  products  are  received. 

1.2  Establish  and  maintain  the  environment  needed  to  support  validation. 

Plans  should  identify  adequate  resources  to  execute  validation  activities. 

1.3  Establish  and  maintain  procedures  and  criteria  for  validation. 

2.  The  product  or  product  components  are  validated  to  ensure  that  they  are  suitable 
for  use  in  their  intended  operating  environment. 

2.1  Perform  validation  on  the  selected  products  and  product  components. 

2.2  Analyze  the  results  of  the  validation  activities  and  identify  issues. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Validation,  see  the  source  docu¬ 
ments  referenced  in  the  bibliography. 
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3.3  Support  Process  Areas 

The  support  process  areas  include  the  processes  and  tools  required  to  allow  projects  to  effec¬ 
tively  apply  measurement  and  decision  techniques  to  manage  the  project.  In  addition,  they 
include  activities  to  ensure  the  products  or  capabilities  acquired  can  be  transitioned  into  op¬ 
erational  use  and  maintained  during  the  operational  life  of  the  product  or  capability. 


Decision  Analysis  and  Resolution  (DAR) 

The  purpose  of  Decision  Analysis  and  Resolution  is  to  analyze  possible  decisions  using  a 
formal  evaluation  process  that  evaluates  identified  alternatives  against  established  criteria. 

For  acquisition,  a  repeatable  criteria-based  decision-making  process  is  especially  important, 
both  while  making  the  critical  decisions  that  define  and  guide  the  acquisition  process  itself 
and  later  when  critical  decisions  are  made  with  the  selected  supplier.  The  establishment  of  a 
formal  process  for  decision-making  provides  the  acquisition  project  with  documentation  of 
the  decision  rationale.  Such  documentation  allows  the  criteria  for  critical  decisions  to  be 
revisited  when  changes  that  impact  project  requirements  or  other  critical  project  parameters 
change. 

Decision  Analysis  and  Resolution  can  best  be  described  by  the  following  goals  and  practices. 

1.  Decisions  are  based  on  an  evaluation  of  alternatives  using  established  criteria. 

1.1  Establish  and  maintain  guidelines  to  determine  which  issues  are  subject  to  a  formal 
evaluation  process. 

Not  every  decision  is  significant  enough  to  require  a  formal  evaluation  process.  The 
choice  between  the  trivial  and  the  truly  important  may  be  unclear  without  explicit 
guidance .  The  significance  of  a  particular  decision  is  dependent  on  the  project  and 
circumstances  and  is  determined  by  the  established  guidelines . 

1.2  Establish  and  maintain  the  criteria  for  evaluating  alternatives  and  the  relative  ranking 
of  these  criteria. 

Regular  use  of  decision-making  criteria ,  even  for  less  significant  decisions,  can  be 
extremely  helpful  in  creating  a  practice  for  disciplined  decision  making.  Practiced, 
evaluators  have  demonstrated  that  defined  criteria  and  weighting  can  be  a 
significant  contributor  to  the  speed  and  consensus  level  of  a  decision. 

1.3  Identify  alternative  solutions  to  address  issues. 

A  wider  range  of  alternatives  can  surface  by  soliciting  as  many  stakeholders  as 
practical  for  input.  Input  from  stakeholders  with  diverse  skills  and  backgrounds  can 
help  teams  identify  and  address  assumptions,  constraints,  and  biases.  Brainstorming 
sessions,  with  support  from  the  stakeholder,  may  stimulate  innovative  alternatives 
through  rapid  interaction  and  feedback. 

1.4  Select  the  evaluation  methods. 

1.5  Evaluate  alternative  solutions  using  the  established  criteria  and  methods. 
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1 .6  Select  solutions  from  the  alternatives  based  on  the  evaluation  criteria. 


Document  the  results  of  the  evaluation  for  future  reference. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Decision  Analysis  and  Resolution, 
see  the  source  documents  referenced  in  the  bibliography. 


Measurement  and  Analysis  (MA) 

The  purpose  of  Measurement  and  Analysis  is  to  develop  and  sustain  a  measurement  capabil¬ 
ity  that  is  used  to  support  management  information  needs. 

For  acquisition,  the  acquisition  project  has  information  needs  for  determining  the  status  of 
its  activities  throughout  the  life  cycle  of  the  acquisition,  the  supplier’s  activities  per 
contractual  requirements,  and  the  status  of  the  evolving  products  acquired.  In  acquisition 
projects  where  multiple  products  are  acquired  to  deliver  a  capability  to  the  end  user,  or  where 
there  are  teaming  relationships  with  other  acquisition  projects  to  acquire  joint  capabilities, 
additional  information  needs  may  be  identified  to  ensure  programmatic,  technical,  and 
operational  interoperability  product  objectives  are  identified,  measured,  and  achieved. 

Measurement  and  Analysis  can  best  be  described  by  the  following  goals  and  practices. 

1.  Measurement  objectives  and  activities  are  aligned  with  identified  information  needs 
and  objectives. 

Not  all  measurements  are  valuable.  Those  that  address  the  needs  and  objectives  of  the 
acquisition  project  are  the  most  valuable.  It  is  best  to  identify  those  measures  that  are 
focused  on  the  objectives,  rather  than  measures  that  are  easily  obtained  but  have 
questionable  value. 

1 . 1  Establish  and  maintain  measurement  objectives  that  are  derived  from  identified 
information  needs  and  objectives. 

Identify  what  information  is  needed  to  keep  the  acquisition  on  track  to  a  successful 
conclusion.  Establish  what  measurement  objectives  and  measurement  criteria  are 
needed  to  provide  this  information. 

1.2  Specify  measures  to  address  the  measurement  objectives. 

1.3  Specify  how  measurement  data  will  be  obtained  and  stored. 

1.4  Specify  how  measurement  data  will  be  analyzed  and  reported. 

2.  Measurement  results  that  address  identified  information  needs  and  objectives  are 
provided. 

2. 1  Obtain  specified  measurement  data. 

2.2  Analyze  and  interpret  measurement  data. 

2.3  Manage  and  store  measurement  data,  measurement  specifications,  and  analysis 
results. 

2.4  Report  results  of  measurement  and  analysis  activities  to  all  relevant  stakeholders. 
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For  more  extensive  treatment  of  the  goals  and  practices  of  Measurement  and  Analysis,  see  the 
source  documents  referenced  in  the  bibliography. 


Transition  to  Operations  and  Support  (TOS) 

The  purpose  of  Transition  to  Operations  and  Support  is  to  provide  for  the  transition  of  the 
product  to  the  end  user  and  the  eventual  support  organization  and  to  accommodate  life-cycle 
evolution  of  the  product. 

For  acquisition ,  Transition  to  Operations  and  Support  involves  the  processes  used  to  plan  for 
and  manage  the  transition  of  new  or  evolved  products  into  operational  use  and  their 
transition  to  the  eventual  maintenance  or  support  organization.  Identify  any  special 
conditions  that  may  apply  during  the  eventual  decommissioning  or  disposal  of  the  products. 
The  acquisition  project  is  responsible  for  ensuring  the  acquired  products  not  only  meet 
specified  requirements  (see  the  Verification  process  area)  and  can  be  used  in  the  intended 
environment  (see  the  Validation  process  area)  but  also  that  they  can  be  transitioned  into 
operational  use  to  achieve  the  users'  desired  mission  capabilities  and  can  be  maintained  and 
sustained  over  their  intended  life  cycles.  The  acquisition  project  is  responsible  for  ensuring 
reasonable  planning  for  transition  into  operations  is  conducted ,  clear  transition  criteria  exist 
and  are  agreed  to  by  relevant  stakeholders,  and  planning  is  completed  for  product 
maintenance  and  support  of  products  after  they  become  operational.  These  plans  include 
reasonable  accommodation  for  known  and  potential  evolution  of  the  products  and  their 
eventual  removal  from  operational  use. 

Transition  to  Operations  and  Support  can  best  be  described  by  the  following. 

1.  Preparation  for  transition  to  operations  and  support  is  conducted. 

1 . 1  Establish  and  maintain  a  strategy  for  transition  to  operations  and  support. 

Planning  for  transition  includes  establishing  the  strategy  for  support  (e.g.,  source  of 
repair)  through  organic  support  infrastructures,  contractor  logistics  support ,  or 
other  sources.  It  can  also  include  defining  the  levels  of  support  to  be  established 
( e.g.,  organization,  intermediate,  depot).  The  strategy  is  important  because  it  drives 
most  of  the  other  transition  planning  activities,  as  well  as  product  design 
considerations. 

1.2  Establish  and  maintain  plans  for  transitioning  acquired  products  into  operational  use 
and  support. 

Transition  plans  for  products  should  be  consistent  with  the  overall  transition  strategy 
and  agreed  to  by  relevant  stakeholders. 

1.3  Establish  and  maintain  training  requirements  for  operational  and  support  personnel. 

1.4  Establish  and  maintain  initial  and  life-cycle  resource  requirements  for  performing 
operations  and  support. 

This  includes  identifying  and  providing  for  initial  spares,  operational  and  support 
training  capabilities,  facilities,  etc.  Eventual  disposal  of  the  product  should  also  be 
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considered.  Disposal  of  any  existing  products  to  be  replaced  should  also  be 
considered. 

1.5  Identify  and  assign  organizational  responsibility  for  support. 

The  roles  and  responsibilities  of  the  acquirer,  supporter,  and  user  should  be  defined 
for  the  life-cycle  support  of  the  product.  Explicitly  identifying  organizational 
responsibility  for  support  (Le.,  “level  1  maintenance” )  and  for  enhancements  ( i.e ., 
“level  2  maintenance  ”)  ensures  that  relevant  stakeholders  are  involved  early  in  the 
acquisition  projects  planning  processes . 

1.6  Establish  and  maintain  criteria  for  assigning  responsibility  for  enhancements. 

Responsibility  for  capability  enhancements  during  the  support  phase  should  be 
defined.  Criteria  used  to  support  the  assignment  of  responsibilities  should  include  the 
magnitude  and  complexity  of  the  envisioned  change ,  required  domain  knowledge  and 
experience,  and  required  acquisition  expertise. 

1.7  Establish  and  maintain  transition  criteria  for  the  acquired  products. 

2.  Transition  decisions  and  actions  are  executed  in  accordance  with  transition  criteria. 

2. 1  Evaluate  the  readiness  of  the  acquired  products  to  undergo  transition  to  operations 
and  support. 

Readiness  is  evaluated  throughout  the  acquisition  life  cycle  based  upon  transition 
criteria.  Definition  of  the  transition,  criteria  supports  an  objective  evaluation  of  the 
products' readiness  for  transition. 

2.2  Evaluate  the  readiness  of  the  operational  and  support  personnel  to  assume 
responsibility  for  the  acquired  products. 

Readiness  is  evaluated  throughout  the  acquisition  life  cycle  based  upon  transition 
criteria.  Using  the  previously  defined  transition  criteria,  objectively  evaluate  the 
products '  readiness  for  transition. 

2.3  Analyze  the  results  of  all  transition  activities  and  identify  appropriate  action. 

As  a  result  of  analysis,  transition  activities  and  actions  may  be  required  of  the 
acquisition  project,  the  supplier,  the  user,  or  the  support  organization.  The  analysis 
may  also  identify  areas  for  improvement  in  future  transition  activities. 

For  more  extensive  treatment  of  the  goals  and  practices  of  Transition  to  Operations  and  Sup¬ 
port,  see  the  source  documents  referenced  in  the  bibliography. 
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4  Generic  Practices 


Generic  practices  are  practices  that  should  be  included  in  every  process  area,  in  addition  to 
the  specific  practices  that  appear  in  each  process  area  description.  Generic  practices  improve 
the  power  of  a  process  by  ensuring  that  the  specific  practices  are  executed  and  that  there  is 
appropriate  planning  of  the  process  to  ensure  that  it  is  feasible  and  well  supported  and  that 
stakeholders  are  properly  involved. 

In  this  section,  practices  are  denoted  by  bold-faced  text  and  followed  by  a  brief  explanation. 
The  last  two  generic  practices  documented  in  this  section  ensure  that  the  performance  of  each 
process  and  the  lessons  learned  are  saved  and  that  this  knowledge  is  used  to  establish  new 
projects  or  to  improve  the  performance  of  an  existing  project. 

1.  Establish  and  maintain  an  organizational  policy  for  planning  and  performing  the 
process. 

The  purpose  of  this  generic  practice  is  to  define  the  organizational  expectations  for  the  proc¬ 
ess  and  make  these  expectations  visible  to  those  in  the  organization  who  are  affected.  In  gen¬ 
eral,  senior  management  is  responsible  for  establishing  and  communicating  guiding  princi¬ 
ples,  direction,  and  expectations  for  the  organization. 

Not  all  direction  from  senior  management  will  bear  the  label  “policy.”  The  existence  of  ap¬ 
propriate  organizational  direction  is  the  expectation  of  this  generic  practice,  regardless  of 
what  it  is  called  or  how  it  is  imparted. 

2.  Establish  and  maintain  the  plan  for  performing  the  process. 

The  purpose  of  this  generic  practice  is  to  determine  what  is  needed  to  perform  the  process 
and  achieve  the  established  objectives,  to  prepare  a  plan  for  performing  the  process,  to  pre¬ 
pare  a  process  description,  and  to  get  agreement  on  the  plan  from  relevant  stakeholders. 

Planning  of  a  process  applies  to  all  process  areas  including  Project  Planning.  The  process  for 
planning  the  project  requires  planning  (e.g.,  resource,  duration)  just  like  any  other  activity. 

The  objectives  for  the  process  may  be  derived  from  other  plans  (e.g.,  the  project  plans).  In¬ 
cluded  are  objectives  for  the  specific  situation,  including  quality,  cost,  and  schedule  objec¬ 
tives.  For  example,  an  objective  might  be  to  reduce  the  cost  of  performing  a  process  for  an 
implementation  over  its  previous  implementation. 

Establishing  a  plan  includes  documenting  the  plan  and  providing  a  process  description.  Main¬ 
taining  the  plan  includes  changing  it  as  necessary  in  response  to  either  corrective  actions  or  to 
changes  in  requirements  and  objectives  for  the  process. 
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The  plan  for  performing  the  process  typically  includes  the  following  elements: 

•  process  description 

•  standards  for  the  work  products  and  services  of  the  process 

•  requirements  for  the  work  products  and  services  of  the  process 

•  specific  objectives  for  the  performance  of  the  process  (e.g.,  quality,  time  scale,  cycle 
time,  and  resource  usage) 

•  dependencies  among  the  activities,  work  products,  and  services  of  the  process 

•  resources  (including  funding,  people,  and  tools)  needed  to  perform  the  process 

•  assignment  of  responsibility  and  authority 

•  training  needed  for  performing  and  supporting  the  process 

•  work  products  to  be  placed  under  configuration  management  and  the  level  of  configura¬ 
tion  management  for  each  item 

•  measurement  requirements  to  provide  insight  into  the  performance  of  the  process,  its 
work  products,  and  its  services 

•  involvement  of  identified  stakeholders 

•  activities  for  monitoring  and  controlling  the  process 

•  objective  evaluation  activities  for  the  process  and  the  work  products 

•  management  review  activities  for  the  process  and  the  work  products 

3.  Provide  adequate  resources  for  performing  the  process,  developing  the  work 
products,  and  providing  the  services  of  the  process. 

This  generic  practice  ensures  that  the  resources  necessary  to  perform  the  process  as  defined 
by  the  plan  are  available  when  they  are  needed.  Resources  include  adequate  funding,  appro¬ 
priate  physical  facilities,  skilled  people,  and  appropriate  tools. 

4.  Assign  responsibility  and  authority  for  performing  the  process,  developing  the 
work  products,  and  providing  the  services  of  the  process. 

This  generic  practice  ensures  that  there  is  accountability  for  performing  the  process  and 
achieving  the  specified  results  throughout  the  life  of  the  process.  The  people  chosen  should 
have  the  appropriate  authority  to  perform  the  assigned  responsibilities. 

Responsibility  can  be  assigned  using  detailed  job  descriptions  or  in  living  documents,  such  as 
the  plan  for  performing  the  process.  Dynamic  assignment  of  responsibility  is  another  legiti¬ 
mate  way  to  perform  this  generic  practice,  as  long  as  the  assignment  and  acceptance  of  re¬ 
sponsibility  are  ensured  throughout  the  life  of  the  process. 

5.  Train  the  people  performing  or  supporting  the  process  as  needed. 

This  generic  practice  ensures  that  the  people  have  the  necessary  skills  and  expertise  to  per¬ 
form  or  support  the  process. 
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Training  supports  the  successful  performance  of  the  process  by  establishing  a  common  un¬ 
derstanding  of  the  process  and  by  imparting  the  skills  and  knowledge  needed  to  perform  the 
process. 

6.  Place  designated  work  products  of  the  process  under  appropriate  levels  of 
configuration  management. 

This  generic  practice  establishes  and  maintains  the  integrity  of  the  designated  work  products 
of  the  process  (or  their  descriptions)  throughout  their  useful  life. 

The  designated  work  products  are  specifically  identified  in  the  plan  for  performing  the  proc¬ 
ess,  along  with  a  specification  of  the  level  of  configuration  management. 

7.  Identify  and  involve  the  relevant  stakeholders  as  planned. 

This  generic  practice  establishes  and  maintains  the  expected  involvement  of  stakeholders  dur¬ 
ing  the  execution  of  the  process. 

The  objective  of  planning  the  stakeholder  involvement  is  to  ensure  that  interactions  necessary 
to  the  process  are  accomplished,  while  not  allowing  excessive  numbers  of  affected  groups 
and  individuals  to  impede  process  execution. 

8.  Monitor  and  control  the  process  against  the  plan  for  performing  the  process  and 
take  appropriate  corrective  action. 

The  purpose  of  this  generic  practice  is  to  perform  the  direct  day-to-day  monitoring  and  con¬ 
trolling  of  the  process.  Appropriate  visibility  into  the  process  is  maintained  so  that  appropri¬ 
ate  corrective  action  can  be  taken  when  necessary.  Monitoring  and  controlling  the  process 
involves  measuring  appropriate  attributes  of  the  process  or  work  products  produced  by  the 
process. 

9.  Objectively  evaluate  adherence  of  the  process  against  its  process  description, 
standards,  and  procedures,  and  address  noncompliance. 

This  generic  practice  provides  credible  assurance  that  the  process  is  implemented  as  planned 
and  adheres  to  its  process  description,  standards,  and  procedures. 

10.  Review  the  activities,  status,  and  results  of  the  process  with  higher  level 
management  and  resolve  issues. 

The  purpose  of  this  generic  practice  is  to  provide  higher  level  management  with  the  appropri¬ 
ate  visibility  into  the  process. 

Higher  level  management  includes  those  levels  of  management  in  the  organization  above  the 
immediate  level  of  management  responsible  for  the  process.  In  particular,  higher  level  man¬ 
agement  includes  senior  management.  These  reviews  are  for  managers  who  provide  the  pol¬ 
icy  and  overall  guidance  for  the  process,  not  for  those  who  perform  the  direct  day-to-day 
monitoring  and  controlling  of  the  process. 
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The  two  following  generic  practices  form  the  basis  for  propagating  good  practice  to  future 
acquisition  projects.  They  facilitate  process  definition  and  identify  process  benefits  that 
encourage  adoption  of  best  practices  on  new  projects. 

A  defined  process  is  tailored  from  the  organization’s  set  of  standard  processes  according  to 
the  organization’s  tailoring  guidelines  and  contributes  work  products,  measures,  and  other 
process-improvement  information  to  the  organizational  process  assets. 

These  two  generic  practices  activate  a  process  improvement  cycle.  The  organization  main¬ 
tains  a  process  asset  library  and  standard  process  that  can  be  drawn  upon  by  a  project  to  cre¬ 
ate  its  processes.  In  turn,  the  project  provides  information  about  the  performance  of  its  proc¬ 
ess  to  the  organization’s  process  asset  library,  which  is  used  to  improve  and  extend  the 
standard  processes. 

The  organization’s  set  of  standard  processes,  which  are  the  basis  of  the  defined  process,  are 
established  and  improved  over  time.  Standard  processes  describe  the  fundamental  process 
elements  that  are  expected  in  the  defined  processes.  Standard  processes  also  describe  the  rela¬ 
tionships  (e.g.,  the  ordering  and  interfaces)  between  these  process  elements.  The  organiza¬ 
tion-level  infrastructure  to  support  current  and  future  use  of  the  organization’s  set  of  standard 
processes  is  established  and  improved  over  time. 

11.  Establish  and  maintain  the  description  of  a  defined  process. 

The  purpose  of  this  generic  practice  is  to  establish  and  maintain  a  description  of  the  process 
that  is  tailored  from  the  organization’s  set  of  standard  processes  to  address  the  needs  of  a  spe¬ 
cific  instantiation.  The  organization  should  have  standard  processes  that  cover  the  process 
area,  as  well  as  guidelines  for  tailoring  these  standard  processes  to  meet  the  needs  of  a  project 
or  organizational  function.  With  a  defined  process,  variability  in  how  the  processes  are  per¬ 
formed  across  the  organization  is  reduced  and  process  assets,  data,  and  learning  can  be  effec¬ 
tively  shared. 

12.  Collect  work  products,  measures,  measurement  results,  and  improvement 
information  derived  from  planning  and  performing  the  process  to  support  the 
future  use  and  improvement  of  the  organization’s  processes  and  process  assets. 

The  purpose  of  this  generic  practice  is  to  collect  information  and  artifacts  derived  from  plan¬ 
ning  and  performing  the  process.  This  generic  practice  is  performed  so  that  the  information 
and  artifacts  can  be  included  in  the  organizational  process  assets  and  made  available  to  those 
who  are  (or  who  will  be)  planning  and  performing  the  same  or  similar  processes.  The  infor¬ 
mation  and  artifacts  are  stored  in  the  organization’s  measurement  repository  and  the  organiza¬ 
tion’s  process  asset  library. 
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Appendix  Improving  Acquisition  Prac¬ 
tices 


Project-Level  Process  Improvement 

Acquisition  projects  are  concerned  with  ensuring  the  practices  they  perform  effectively  re¬ 
duce  risks  associated  with  common  management,  engineering,  and  support  issues  that  arise 
during  the  performance  of  the  project.  The  specific  practices,  along  with  the  generic  practices 
for  each  process  area,  represent  the  set  of  project-level  practices  and  can  be  used  to  identify 
gaps  in  implementation  or  process-related  risks  to  the  project.  Careful  use  of  selected  meas¬ 
ures  can  help  gain  insight  into  the  effectiveness  of  project-level  process  implementation. 

In  addition,  higher  level  acquisition  organizations  with  multiple  projects  or  with  oversight 
responsibility  can  use  these  practices  to  identify  areas  that  may  require  process  improvement 
focus.  A  project  that  has  well-defined  processes  has  a  greater  ability  to  deal  with  risk  and 
complexity. 

Organizational  Process  Improvement 

Process  improvement  at  the  organizational  level  is  concerned  with  creating  an  effective  envi¬ 
ronment  and  infrastructure  to  allow  acquisition  projects  within  the  organization’s  span  of 
control  greater  probability  to  succeed.  When  a  project  has  clear  guidance,  starter  templates, 
historical  data,  and  a  strong  process  culture  at  the  organizational  level,  it  is  more  likely  to 
sustain  effective  practices  and  ultimately  achieve  its  goals. 

Acquisition  organizations  can  improve  by  working  with  successful  projects  to  capture  suc¬ 
cess  stories,  measure  the  effectiveness  of  processes  across  their  projects,  and  begin  to  build  a 
standard  set  of  acquisition  practices,  proven  by  their  success  in  real  projects,  for  use  in  subse¬ 
quent  projects.  Senior  leaders  can  establish  an  infrastructure  and  strong  process  culture  that 
reward  projects  that  build  realistic  plans  and  execute  according  to  those  plans. 

Acquisition  organizations  can  improve  both  the  capability  of  their  organization  processes  as 
well  as  the  capability  of  selected  project-level  processes  across  their  organization  using  the 
CMMI-AM  in  conjunction  with  selected  process  areas  from  the  CMMI  framework.  Process 
areas  from  the  CMMI  framework  to  explore  when  improving  organizational  capability  in¬ 
clude  Organizational  Process  Focus,  Organizational  Process  Definition,  and  Organizational 
Training. 
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